Identity is well understood in the physical world, but is a current challenge in the digital world. In the physical world, people present a passport at an airport's Immigration Desk, a driver's license to a police officer, a credit card to pay for a best-selling novel at a bookstore, and various other types of identification in a variety of situations. In the digital world, people may log onto websites using a username and password, provide shipping and credit card information to an online retailer, use a smartcard to log onto a corporate network, and so forth.
Despite their diversity, digital identities all have one thing in common: when transmitted on the network, every digital identity is represented by some kind of security token. A security token is just a set of bytes that expresses information about a digital identity. This information includes one or more claims asserted to be true by the token's issuer, each of which contains some part of the total information conveyed about this identity. A simple security token might include only a claim containing a username, while a more complex one might include claims containing a user's first name, last name, home address, and more. Security tokens for some digital identities might also include claims that contain sensitive information such as credit card numbers.
With most security systems, some information is provided in order to prove that these claims really do belong to the user presenting them. One simple (and currently very common) way to do this is to send a password along with the claims. A more powerful approach is for the user to prove claims ownership using a private key associated with a public key that has been signed along with the disclosed claims by the issuer. Regardless of the method, the security tokens that represent digital identities commonly provide some kind of proof that allows a receiver of the token to verify that this token really does represent the person or service presenting the token.
Numerous systems exist for providing digital identity and authentication. Rather than each website or service building and maintaining its own authentication system, federated authentication has become a popular paradigm. Using federated authentication, a relying party (RP) (e.g., a website that wants to differentiate its services based on the particular user) relies on an identity provider (IdP) to provide an initial digital identity for users by means of the identity provider's authentication service. The security token from the identity provider is presented to the relying party, which accepts that token as proof of the user's identity, and proceeds on that basis with its own user-relative features. For example, many websites now allow users to prove their identity using a token provided by an initial authenticated connection to Facebook.
More and more web sites are using identity federation to facilitate user registration and authentication. By allowing a visitor to reuse an existing digital identity, friction can be reduced and registration/logon rates can go up significantly. Sites that rely on third party identity providers to authenticate users are known as relying parties. Additional benefits to relying parties include a reduced cost for account management (e.g., lost password recovery, dealing with hijacked accounts, and so on) and the ability to leverage additional user-relative data from the identity provider such as a verified email address, personal identifiable information, social graph, and so forth. In other words, additional, often more valuable data can be accumulated in a user's profile without the cost and burden of full registration and account management machinery.
As more and more online services rely on federated authentication and, thus, identity providers, the risk of an outage at an identity provider making a large number of online services unavailable increases. An identity provider may suffer an outage for a variety of reasons, such as planned maintenance, hardware or software failures, natural disasters, severed communications infrastructure, or some local or transient communications outage that makes a particular user's client computer or relying party's computer unable to connect to the identity provider even though the identity provider is operating normally. Outages may also come in the form of an identity provider deleting a user's account or simply going out of business.
This wide range of possible outages mean that a relying party may suffer a derivative outage of all user-relative services over which it has no control because its users cannot authenticate themselves. In order to provide continuity of service, the relying party may feel compelled to build a parallel authentication infrastructure for authenticating users during identity provider outages. The former (failure of a relying party due to identity provider failures) is unacceptable to users, and the latter (building a back-up authentication system) defeats the offloading of development and maintenance effort that are the main purpose of federated authentication. A parallel authentication infrastructure that is rarely used may also create a weak link in security that can be exploited by malicious users.
In sum, one of the major weaknesses of the federated model is that relying parties take a dependency on the identity provider for user authentication. As a result, outage at an identity provider results in an inability for federated users of that identity provider to log on to the relying party's service. The risk of (small) identity providers going out of business or terminating user accounts (e.g., after a period of inactivity at the identity provider's site) also contribute to an increased risk for relying parties that rely on independent identity providers.